home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-avt-rtp-00.txt < prev    next >
Text File  |  1993-03-03  |  29KB  |  694 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Engineering Task Force                     Audio-Video Transport WG
  8. INTERNET-DRAFT                                                H. Schulzrinne
  9.                                                       AT&T Bell Laboratories
  10.                                                            December 15, 1992
  11.                                                             Expires:  5/1/93
  12.  
  13.  
  14.               A Transport Protocol for Real-Time Applications
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.  
  21. This document is an Internet Draft.   Internet Drafts are working  documents
  22. of the Internet Engineering  Task Force (IETF), its  Areas, and its  Working
  23. Groups.   Note that other  groups may also  distribute working documents  as
  24. Internet Drafts).
  25.  
  26. Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
  27. Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
  28. at any time.   It  is not appropriate  to use Internet  Drafts as  reference
  29. material or  to cite  them  other than  as a  "working  draft" or  "work  in
  30. progress."
  31.  
  32. Please check  the I-D  abstract  listing contained  in each  Internet  Draft
  33. directory to learn the current status of this or any other Internet Draft.
  34.  
  35. Distribution of this document is unlimited.
  36.  
  37.  
  38.                                   Abstract
  39.  
  40.  
  41.      This  draft describes a protocol (RTP)  suitable for the transport
  42.     of  real-time  data,  such  as audio,   video or  simulation  data.
  43.     The  data transport  is  enhanced by  a  control protocol  designed
  44.     to provide  minimal control  and identification  functionality.   A
  45.     reverse control protocol provides mechanisms for monitoring quality
  46.     of service and  other content-specific requests.   This protocol is
  47.     intended for experimental use.
  48.  
  49.  
  50. 1 Introduction
  51.  
  52.  
  53. This draft concisely specifies a real-time transport protocol.  A discussion
  54. of the design decisions can be found in the current version of the companion
  55. Internet draft draft-ietf-avt-issues.txt.   The transport protocol  provides
  56.  
  57.  
  58. INTERNET-DRAFT                     RTP                     December 15, 1992
  59.  
  60. end-to-end delivery services for  one or more flows  of data with  real-time
  61. characteristics, for example,  interactive audio  and video.    It does  not
  62. guarantee delivery or prevent out-of-order delivery, nor does it assume that
  63. the underlying network is  reliable and delivers packets  in sequence.   RTP
  64. is designed to run on top of  a variety of network and transport  protocols,
  65. for example, IP,  ST-II or UDP.  RTP transfers data  in a single  direction,
  66. possibly to multiple destinations if supported by the underlying network.  A
  67. mechanism for indicating a return path for control data is provided.
  68.  
  69. While RTP is  primarily designed  to satisfy the  needs of  multiparticipant
  70. multimedia conferences, it  is not limited  to that particular  application.
  71. Storage of continuous data,  interactive distributed simulation and  control
  72. and measurement applications  may also find  RTP applicable.   Profiles  are
  73. used to instantiate certain header fields and options for particular sets of
  74. applications.
  75.  
  76. This document defines two packet formats and protocols:
  77.  
  78.  
  79.   o the  real-time  transport  protocol  (RTP)  for  exchanging  data   with
  80.     real-time properties.
  81.  
  82.   o the real-time  control protocol (RTCP)  for conveying information  about
  83.     the sites in an on-going  association.  RTCP information may be  ignored
  84.     without affecting the ability to correctly receive information.
  85.  
  86.  
  87. Control fields  (options) for  RTP and  RTCP share  the same  structure  and
  88. numbering space and are carried  within the same packet.   Within a  packet,
  89. RTP options precede RTCP options.   Each option  consists of the final  bit,
  90. the option type  designation, a  one-octet length field  denoting the  total
  91. number of 32-bit long words comprising the option (including final bit, type
  92. and length), and finally any option-specific  data.  The last option  before
  93. the packet data portion has  the 'F' (final) bit set  to one, for all  other
  94. options this field has a value of zero.
  95.  
  96. Field within the fixed header and within options are aligned to the  natural
  97. length of  the field,  i.e., 16-bit  words are  aligned  on even  addresses,
  98. 32-bit long words are aligned at addresses  divisible by four, etc.   Octets
  99. designated as padding  have the  value zero.    Options unknown  to the  RTP
  100. implementation or the application  are to be ignored.   Options with  option
  101. types having values  from 64 to  127 inclusive are  passed unaltered to  the
  102. appropriate application.   Fields designated  as MBZ ('must  be zero')  must
  103. have a value of binary zero and are to be ignored by the receiver.
  104.  
  105. All integer  fields  are  carried in  network  byte  order,  that  is,  most
  106. significant byte (octet)  first.   The  transmission order  is described  in
  107. detail in [1], Appendix A. Unless otherwise noted, constants are in  decimal
  108. (base 10).
  109.  
  110.  
  111.  
  112.  
  113. H. Schulzrinne                    Expires 5/1/93                    [Page 2]
  114.  
  115.  
  116. INTERNET-DRAFT                     RTP                     December 15, 1992
  117.  
  118. 2 Real-time Data Transfer Protocol -- RTP
  119.  
  120.  
  121.  
  122. 2.1 Framing
  123.  
  124.  
  125. If and only if  RTP protocol data units  (RPDU) are carried over  underlying
  126. protocols that provide  the abstraction  of a continuous  bit stream  rather
  127. than messages,  each RPDU  (and any  synchronization source  identifier,  as
  128. defined below) is prefixed by a  32-bit framing field containing the  length
  129. of the  RPDU  measured  in  octets,  including  the  synchronization  source
  130. identifier, but not including the framing field itself.  If a RPDU traverses
  131. a mixture  of  octet-stream  and  message-oriented  networks,  each  gateway
  132. between these networks is  responsible for adding  and removing the  framing
  133. field.
  134.  
  135.  
  136. 2.2 Synchronization Source Encapsulation
  137.  
  138.  
  139. A content source is  defined to be  the actual source  of the data  carried,
  140. for example, the application and workstation where the audio was  digitized.
  141. The synchronization  source  is  the  combination of  one  or  more  content
  142. sources with its own timing.   A network source is the network-level  origin
  143. of the  RPDUs as  seen  by the  end system.    Unless  otherwise  specified,
  144. the content  source  and  synchronization  source are  both  assumed  to  be
  145. identical to the  network source.    If the  synchronization source  differs
  146. from the network  source,  the RPDU  is prefixed  with a  32-bit IP  address
  147. designating the network source.  This encapsulation may be used by  gateways
  148. and transport-level firewalls.    The end system  has to  determine by  some
  149. means outside  this specification  whether  it is  being  served by  such  a
  150. facility.  [NOTE:  The method of determining  whether encapsulation is  used
  151. or not is unsatisfactory, particularly for sites where only some  conference
  152. participants are connected  through reflectors.   The method  was chosen  to
  153. allow reflectors to be independent of the protocol particulars.]
  154.  
  155. A synchronization unit consists  of one or  more packets that,  as a  group,
  156. share a common fixed  delay between generation and  playout of each part  of
  157. the group, or can only be scheduled as a whole.  The delay may change at the
  158. beginning of such a synchronization unit.   The most common  synchronization
  159. units are talkspurts for voice and frames for video transmission.
  160.  
  161.  
  162. 2.3 RTP Header Fields
  163.  
  164.  
  165. The header fields have the following meaning:
  166.  
  167.  
  168.  
  169.  
  170.  
  171. H. Schulzrinne                    Expires 5/1/93                    [Page 3]
  172.  
  173.  
  174. INTERNET-DRAFT                     RTP                     December 15, 1992
  175.  
  176. protocol version: 2 bits
  177.     Defines  the protocol  version.    The version  number of  the  protocol
  178.     defined in this draft is one.
  179.  
  180. flow: 6 bits
  181.     The value of the field is the flow identifier, one of the items  used by
  182.     the receiver for demultiplexing.
  183.  
  184. option present bit (O): 1 bit
  185.     This flag has a value of one if the fixed RTP header is followed  by one
  186.     or more options.
  187.  
  188. end-of-synchronization-unit (S): 1 bit
  189.     This flag has  a value of  one in the last  packet of a  synchronization
  190.     unit, a value of zero otherwise.
  191.  
  192. content: 6 bits
  193.     The  content  field forms  an  index  into a  table  defined  through  a
  194.     conference announcement  protocol (to  be specified),  RTCP messages,  a
  195.     conference server or  some other out-of-band means.   If no mapping  has
  196.     been defined in this manner,  a standard mapping to be specified by  RFC
  197.     1340, Assigned Numbers, or its successor, is to be used.
  198.  
  199. sequence number: 16 bits
  200.     The sequence number counts RPDUs.
  201.  
  202. timestamp: 32 bits
  203.     The timestamp reflects the  wallclock time when the RPDU was  generated.
  204.     The timestamp consists of the middle 32 bits of a 64-bit  NTP timestamp,
  205.     as defined in RFC 1305.  Note that several consecutive packets  may have
  206.     equal timestamps.  The maximum difference between the timestamp  and the
  207.     true time is encoded in the RTCP CDESC option.
  208.  
  209.     The  timestamp of  the first  packet(s)  within a  synchronization  unit
  210.     is expected  to closely  reflect the actual  sampling instant,  measured
  211.     by the  local system  clock.    It is  not expected  that the  timestamp
  212.     of the  beginning of  every synchronization  unit  is based  on a  local
  213.     synchronized system  clock.   However,  the local clock  should be  used
  214.     frequently enough so that clock drift between synchronized  system clock
  215.     and sampling clock can be compenssated for gradually.  The  local system
  216.     clock should be  controlled by a  time synchronization protocol such  as
  217.     NTP. For packets  inside a synchronization unit,  it may be  appropriate
  218.     to compute timestamps  based on the logical  timing relationships.   For
  219.     audio samples, for example,  the nominal sampling interval may be  used.
  220.     If  the clock  quality  field of  the  CDESC option  does  not  indicate
  221.     otherwise,  it is  assumed that  the  timestamp at  the beginning  of  a
  222.     synchronization unit is derived from a synchronized system clock.
  223.  
  224.  
  225. The packet  header is  followed by  options,  if any,  and the  media  data.
  226. Optional fields are summarized below.   Unless otherwise noted, each  option
  227.  
  228.  
  229. H. Schulzrinne                    Expires 5/1/93                    [Page 4]
  230.  
  231.  
  232. INTERNET-DRAFT                     RTP                     December 15, 1992
  233.  
  234.  
  235.  0                   1                   2                   3
  236.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  237. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238. | packet length (optional)                                      |
  239. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240. | address of synchronization source (optional)                  |
  241. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  242. |Ver| flow      |0|S|  content  | sequence number               |
  243. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  244. | timestamp (seconds)           | timestamp (fraction)          |
  245. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  246. | options ...                                                   |
  247. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  248.  
  249.                         Figure 1:  RTP header format
  250.  
  251.  
  252. may appear only  once per packet.   Each  packet may contain  any number  of
  253. options.
  254.  
  255.  
  256. CSRC 0   Globally  unique  content  source  identifier.     The  option   is
  257.         replicated within a packet for each  contributor to this packet.   A
  258.         source is identified by a globally unique six-octet string formed by
  259.         concatenating a two-octet numeric source  id unique within the  host
  260.         containing the content source and  a four-octet Internet address  of
  261.         the content source.   The length of  the content source address  and
  262.         thus of the CSRC option may change in the future; a receiver  should
  263.         be prepared to accept identifiers of up to ten octets.  If  missing,
  264.         the network source is considered the content source.
  265.  
  266.  
  267.          0                   1                   2                   3
  268.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  269.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  270.         |F|    CSRC     | length = 2    | id unique within host         |
  271.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  272.         | IP address of content source                                  |
  273.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  274.  
  275. SSRC 1   Globally unique  synchronization source  identifier.    The  format
  276.         of the  option  is  the same  as  the  CSRC option.     This  option
  277.         prevails  over  the  specification  of  the  synchronization  source
  278.         through encapsulation.
  279.  
  280.  
  281.          0                   1                   2                   3
  282.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  283.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  284.         |F|    SSRC     | length = 2    | id unique within host         |
  285.  
  286.  
  287. H. Schulzrinne                    Expires 5/1/93                    [Page 5]
  288.  
  289.  
  290. INTERNET-DRAFT                     RTP                     December 15, 1992
  291.  
  292.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  293.         | IP address of synchronization source                          |
  294.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  295.  
  296. BOP 2   (beginning of playout unit)  16-bit sequence number designating  the
  297.         first packet within the current playout unit.
  298.  
  299.  
  300.          0                   1                   2                   3
  301.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  302.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  303.         |F|     BOP     | length = 1    | sequence number               |
  304.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  305.  
  306.  
  307.  
  308. 3 Real Time Control Packets --- RTCP
  309.  
  310.  
  311. The real-time control protocol  (RTCP) conveys minimal out-of-band  advisory
  312. information during a  conference.   The services provided  by RTCP  services
  313. enhance RTP, but  an end-node does  not have to  implement RTCP features  to
  314. participate in conferences(1).  RTCP does not aim to provide the services of
  315. a conference control protocol  and does not  provide services desirable  for
  316. two-party conversations.
  317.  
  318. Unless otherwise  noted,  control  information is  carried  periodically  as
  319. options within RPDUs.  In the absence of media data, packets containing only
  320. RTCP data are sent periodically to the same multicast group as data packets,
  321. using the same  time-to-live value.   The period  should be varied  randomly
  322. to avoid  synchronization of  all sources  and should  be roughly  inversely
  323. proportional to the number of participants in the conference.  The length of
  324. the period determines, for example, how long a receiver joining a conference
  325. has to wait in the worst case until it can identify the source.   An initial
  326. period varying randomly between 3 and 10 seconds is recommended.
  327.  
  328. The item types are defined below:
  329.  
  330.  
  331. 3.1 Forward Control Options
  332.  
  333.  
  334. The following options are sent in the same direction as the data stream.
  335.  
  336.  
  337. CDESC 32   Content description.
  338.  
  339. ------------------------------
  340.  1. There is  one exception to  that rule:   if an  application sends  CDESC
  341. options, the receiver has to decode these in order to properly interpret the
  342. RTP payload
  343.  
  344.  
  345. H. Schulzrinne                    Expires 5/1/93                    [Page 6]
  346.  
  347.  
  348. INTERNET-DRAFT                     RTP                     December 15, 1992
  349.  
  350.         content:  6 bits
  351.             The  'content'  field  designates  the  index  value  from   the
  352.             'content' fixed header field, with values ranging from 0 to 63.
  353.  
  354.         Return port number:  16 bits
  355.             The return  port number is  defined as  the port to  be used  as
  356.             a destination port  number for transmitting control  information
  357.             from the receiver of  RTP data to its sender.   A value of  zero
  358.             indicates that no control information should be returned.
  359.  
  360.         Clock quality:  8 bits
  361.             Provides an  indication as  to the  sender-perceived quality  of
  362.             the timestamps  in the  RTP header.   The  octet is  interpreted
  363.             as a quantity indicating  the maximum dispersion to a root  time
  364.             server measured  in fractions  of a  second and  expressed as  a
  365.             power of two.
  366.  
  367.             If a source is known to be slaved to NTP, but does not  know its
  368.             dispersion, or  the dispersion  is greater than  TBD, the  value
  369.             TBD is used.   If the clock is based on the nominal sample  rate
  370.             of the source,  a value of TBD is used.   [These values need  to
  371.             be finalized.]
  372.  
  373.             The clock quality indication can be used to judge how  the delay
  374.             measurements reported by the  QOS option can be interpreted  (as
  375.             absolute delay or only as  delay variation).  It is also  useful
  376.             for determining  to what extent  several sources with  different
  377.             clocks can be synchronized.
  378.  
  379.         Content:  32 bits
  380.             The  content field  describes what  type  of data  is  contained
  381.             within the RTP payload; it can be considered as  a next-protocol
  382.             field.     That  field  and  all  bytes  following  it  are  not
  383.             interpreted by RTP, but passed on to the next higher layer.
  384.  
  385.         Content-dependent data:  variable
  386.             Content-dependent data may or may not appear in a  CDESC option.
  387.             It is passed to the next layer and not interpreted by RTP.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403. H. Schulzrinne                    Expires 5/1/93                    [Page 7]
  404.  
  405.  
  406. INTERNET-DRAFT                     RTP                     December 15, 1992
  407.  
  408.         A CDESC  mapping changes  the interpretation  of a  given  'content'
  409.         value starting  at the  packet containing  the CDESC  option.    The
  410.         option only  affects  the  synchronization  source  of  the  packet.
  411.         A  sender  should  refrain  from  changing  the  content  type   and
  412.         flow index  of  a  mapping  defined by  external  means  such  as  a
  413.         conference registry, conference  announcement protocol or  otherwise
  414.         agreed-upon mapping.   Dynamic  changes to these  values may  result
  415.         in misinterpretation of RTP payload if the packet(s) containing  the
  416.         CDESC option are lost.
  417.  
  418.  
  419.           0                   1                   2                   3
  420.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  421.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  422.          |F|    CDESC    |    length     |0|0|  content  | MBZ           |
  423.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  424.          | return port number            | clock quality | MBZ           |
  425.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  426.          | content descriptor                                            |
  427.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  428.         ...  content-dependent data ...                                 ...
  429.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  430.  
  431. SDESC 33   This  option  provides  a   mapping  between  a  numeric   source
  432.         identifier (consisting  of a  two-octet identifier  unique within  a
  433.         host and  a 4-octet  IP address)  and a  human-readable text  string
  434.         describing the source.   The variable-length  string is padded  with
  435.         zeros so that the total length  of the item, including the type  and
  436.         length bytes, is  a multiple of  four bytes.   Examples include  the
  437.         name of a speaker  or the station  identification for a  rebroadcast
  438.         radio station.  The content is not specified or authenticated.   The
  439.         content is encoding according to  ISO standard 10646 (also known  as
  440.         NET-UTF). US-ASCII is a
  441.  
  442.  
  443.           0                   1                   2                   3
  444.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  445.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  446.          |F|    SDESC    |    length     | id unique within host         |
  447.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  448.          | IP address of content or synchronization source               |
  449.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  450.         ... text describing the source                                  ...
  451.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461. H. Schulzrinne                    Expires 5/1/93                    [Page 8]
  462.  
  463.  
  464. INTERNET-DRAFT                     RTP                     December 15, 1992
  465.  
  466. FDESC 34   Flow  content  description.     The  option  describes  the  flow
  467.         corresponding to  the given  flow index,  drawn from  the  numbering
  468.         space used by the  flow index in  the CDESC option.   Character  set
  469.         and padding are the same as for  the SDESC option.  The text  string
  470.         describes the current  content of  the flow.   Example  applications
  471.         include the  session title  for a  conference distribution,  or  the
  472.         current program title for radio or television redistribution through
  473.         packet networks.
  474.  
  475.  
  476.           0                   1                   2                   3
  477.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  478.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  479.          |F| FDESC       |    length     |  text string                  |
  480.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  481.         ...  describing the flow content                                ...
  482.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  483.  
  484. BYE 35   The site specified  by the  host-unique ID  and the  IP address  is
  485.         leaving the conference.    Padded to  32 bit word  length.   If  the
  486.         length is one, the synchronization  source of the packet is  implied
  487.         to be the network source.
  488.  
  489.  
  490.          0                   1                   2                   3
  491.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  492.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  493.         |F|     BYE     | length = 1    |       0       |       0       |
  494.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  495.  
  496.          0                   1                   2                   3
  497.          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  498.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  499.         |F|     BYE     | length = 2    | unique ID within host         |
  500.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  501.         | IP address of source                                          |
  502.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  503.  
  504.  
  505.  
  506. 4 Reverse Control
  507.  
  508.  
  509. This section describes  a means  for the receiver  of RTP  protocol data  to
  510. signal back  to the  sender or  a third  party (reverse  control).   Use  of
  511. reverse control  packets is  optional.   Reverse  control packets  have  the
  512. format shown below.  The packet is preceded by a packet length field  if and
  513. only if the underlying transport layer does not support framing.  The packet
  514. length field contains the number of octets within the packet, not  including
  515. the packet length field itself.
  516.  
  517.  
  518.  
  519. H. Schulzrinne                    Expires 5/1/93                    [Page 9]
  520.  
  521.  
  522. INTERNET-DRAFT                     RTP                     December 15, 1992
  523.  
  524.  0                   1                   2                   3
  525.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  526. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  527. | optional packet length        |
  528. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  529. | flow index    | MBZ           | MBZ           | MBZ           |
  530. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  531. | reverse-control options (variable length) ...                 |
  532. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  533.  
  534. The following options may be used within reverse control packets:
  535.  
  536.  
  537. QOS 64   Quality of service measurement.   The source identifier (as in  the
  538.         CSRC option)  is followed  by  the number  of packets  received  (16
  539.         bits), the number of packets expected (16 bits), the minimum  delay,
  540.         the maximum delay  and the average  delay.   The delay measures  are
  541.         encoded as 6/10 NTP timestamps, that is, six bits encode the  number
  542.         and seconds and 10 bits the fraction of a second.
  543.  
  544.  
  545.           0                   1                   2                   3
  546.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  547.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  548.          |F|     QOS     | length = 5    |    user id                    |
  549.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  550.          | IP address of source                                          |
  551.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  552.          | packets received              | sequence number range         |
  553.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  554.          | minimum delay                 | maximum delay                 |
  555.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  556.          | average delay                 | MBZ                           |
  557.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  558.  
  559. RAD 65   Reverse application data.    The data  contained in  the option  is
  560.         directly passed to the application, without interpretation by RTP.
  561.  
  562.  
  563.           0                   1                   2                   3
  564.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  565.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  566.          |F|    RAD      |    length     | reverse application data      |
  567.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  568.         ...                                                             ...
  569.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577. H. Schulzrinne                   Expires 5/1/93                    [Page 10]
  578.  
  579.  
  580. INTERNET-DRAFT                     RTP                     December 15, 1992
  581.  
  582. Security Considerations
  583.  
  584.  
  585. Security issues  need to  be discussed  before this  draft is  submitted  as
  586. an RFC. RTP suffers  from the same security  deficiencies as the  underlying
  587. protocols, for  example,  the  ability of  an  impostor to  fake  source  or
  588. destination IP address.
  589.  
  590. The usage of network  addresses for identification  within the protocol  has
  591. additional security implications.
  592.  
  593.  
  594.   o false identification of content sources through the CSRC option
  595.  
  596.   o false synchronization source
  597.  
  598.   o BYE sent from site other than content source or  synchronization source;
  599.     this can also be used for denial-of-service attacks
  600.  
  601.  
  602. Impersonation and denial-of-service  attacks can be  made more difficult  by
  603. providing digital signatures for all  or parts of a  message.  IP  multicast
  604. provides no direct  means for  a sender  to know  all the  receivers of  the
  605. data sent.  RTP  options make it easy for  all participants in a  conference
  606. to identify themselves;  if deemed important  for a particular  application,
  607. it is  the  responsibility  of  the application  writer  to  make  listening
  608. without identification difficult.  It should be noted, however, that  within
  609. an internet,  privacy  of  the payload  can  generally only  be  assured  by
  610. encryption.
  611.  
  612. Details of the support for  authentication, encryption and integrity  checks
  613. remain for further study.
  614.  
  615.  
  616.  
  617. Acknowledgments
  618.  
  619.  
  620. This draft  is based  on discussion  within the  IETF audio-video  transport
  621. working group  chaired by  Stephen Casner.    The current  protocol has  its
  622. origins in the Network Voice Protocol  and the Packet Video Protocol  (Danny
  623. Cohen and Randy Cole) and the protocol implemented by the 'vat'  application
  624. (Van Jacobson and Steve McCanne).
  625.  
  626.  
  627. 5 Addresses of Authors
  628.  
  629.  
  630. Stephen Casner
  631. USC/Information Sciences Institute
  632. 4676 Admiralty Way
  633.  
  634.  
  635. H. Schulzrinne                   Expires 5/1/93                    [Page 11]
  636.  
  637.  
  638. INTERNET-DRAFT                     RTP                     December 15, 1992
  639.  
  640. Marina del Ray, CA 90292-6695
  641. Phone:  (213) 822-1511 x153
  642. electronic mail:  casner@isi.edu
  643.  
  644.  
  645.  
  646. Henning Schulzrinne
  647. AT&T Bell Laboratories
  648. MH 2A244
  649. 600 Mountain Avenue
  650. Murray Hill, NJ 07974
  651. telephone:  908 582-2262
  652. electronic mail:  hgs@research.att.com
  653.  
  654.  
  655. References
  656.  
  657.  
  658. [1] J.  Postel, ``Internet  protocol,'' Network  Working  Group Request  for
  659.     Comments RFC 791, Information Sciences Institute, Sept. 1981.
  660.  
  661. [2] D.  L. Mills,  ``Network  time protocol  (version 3)  --  specification,
  662.     implementation  and  analysis,''  Network  Working   Group  Request  for
  663.     Comments RFC 1305, University of Delaware, Mar. 1992.
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693. H. Schulzrinne                   Expires 5/1/93                    [Page 12]
  694.